HTTP
Vortragender: Moritz Blöcker
Veranstaltung: Webasierte Informationssysteme
Einteilung:
Seit wann?
- Nie ein offizieller Standart aber als de Facto Standart HTTP 1.0
in RFC 1945 beschrieben
- Seit 1997 ist HTTP 1.1 in RFC 2068 spezifiziert.
Was ist HTTP ?
- HTTP (HyperText Transfer Protocol) dient wie der Name schon sagt als Protokoll zum Transfer von Daten zwischen 2 Rechnern.
- basiert auf TCP/IP
- Ist ein statusloses Protokoll, d.h. es enthält keine Informationen über die Verbindung zwischen den Übertragungen
- HTTP ist funktioniert mit Plain Text, ist also recht einfach.
Hauptunterschiede zwischen HTTP 1.0 und HTTP 1.1:
HTTP 1.1 wurde gemacht um auf verschiedene Bedürfnisse
einzugehen die nicht von 1.0 abgedeckt wurden.
Wie Funktioniert ein HTTP Transfer?
Der Client ( typischerweise Browser oder Robot) sendet eine Anfrage an den Server.
Der Server schickt darauf hin eine entsprechende Antwort.
Eine Anfrage / Antwort besteht aus:
- Einer ‚initial Line‘ also einer initiierenden Zeile
- Null oder mehr ‚Header Lines‘ bei 1.0 (es gibt 16 Verschiedene)
- Eine oder mehr ‚Header Lines‘ bei 1.1 ( 46 verschiedene)
- Eine Lehrzeile (markiert das Ende vom Head)
- Optional ein ‚Body‘ (ist entweder eine Datei oder eine Nachricht.)
Bei dem Request:
Die Initial Line:
‚Methode‘ ‚URI‘ ‚Benutztes Protokoll‘
Bsp.: GET /path/to/file/index.html HTTP/1.0
Die Methoden:
GET, POST, HEAD
Bei HTTP1.1 gibt es zusätzlich:
PUT, DELETE, OPTIONS und TRACE, diese werden aber kaum benutzt.
Die URI:
ist der ‚Unified Resource Identifier‘ und entspricht der URL
nach dem Host-Namen.
Benutztes Protokoll:
HTTP/1.0 oder HTTP/1.1
Bei der Response:
Die Initial Line (auch genannt Status Line):
‚Benutztes Protokoll‘ ‚Status Code‘ ‚Grund‘
Bsp.:
HTTP/1.0 200 OK
HTTP/1.0 404 Not Found
Der Status Code:
1xx bedeutet: nur Informationen (kein Body) (bei 1.0 nur
zum Experimentieren gedacht)
2xx bedeutet: irgendwie erfolgreich (meist nur 200) der Rest
nur bei Script Prozessen benutzt
3xx bedeutet: Umleitung
4xx bedeutet: Fehler auf der Client-Seite
5xx bedeutet: Fehler auf der Server-Seite
Der Grund:
frei definierbar.
Eine Beispiel Übertragung:
Request:
GET /path/file.html HTTP/1.0
From:
someuser@blabla.comUser-Agent: Mozilla/3.0
[Leere Zeile]
Response:
HTTP/1.0 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/html
Content-Length: 1345
<html>
...
</html>
Die verschiedenen Methoden GET, POST, HEAD, PUT, DELETE:
GET, POST bezieht sich auf die Art, wie der Client Formulardaten
an den Server Überträgt.
GET
Informationen werden über die URL übertragen (nach einem Fragezeichen)
POST
Die Informationen werden als Header-Lines übertragen.
Vorteile:
- Der Benutzer sieht die Daten nicht, da diese im Body
übertragen werden.
- Die Größe ist nicht wie bei GET (256 Zeichen )
beschränkt.
HEAD
Ich will als Client nicht den Message Body haben sondern
nur die Initial Line und die Header Lines.
PUT
Im Body befindet sich ein File der auf den Server gespielt
werden soll (z.B.: Netscape Composer).
DELETE
Es soll ein File auf den Server gelöscht werden
Die wichtigsten Status Codes:
100
200 Die Anfrage ist richtig und wird behandelt
301 dauerhaft umgezogen
302 vorübergehend umgezogen
303
400 Falscher Syntax im Request
401 Zugriff unerlaubt (wenn kein Authoritation Header)
403 Zugriff Verboten
404 Die Quelle wurde nicht gefunden
412
500 Im Server ist was schiefgelaufen
501 Der Server behandelt die Request Methode nicht
503 Server überlastet
Die Header Lines:
Die Header Lines sind nach dem Prinzip Name : Wert aufgebaut.
Hier die Header, die nach der Net-ikett dabei sein sollten:
Client-Seitig:
From: E-Mail, sollte bei Robots gesendet werden
User-Agent
Fehlersuche)
Server-Seitig:
Server: Was für ein Server wird benutzt
Last-Modified:
für’s caching
Client-Seitig u.a. gibt es noch:
HTTP/1.0:
Referer: Von welcher Seite kommt der Benutzer.
If-Modified-Since:
Authorization: beinhalted Benutzername und Passwort
HTTP/1.1:
Host:(muß für HTTP/1.1 dabei sein) Beinhalted nochmal die
Addresse an den der Request geht (für Multi-Domains).
Connection: close für offen gehaltene Verbindungen. Der
Server schließt nach der Response die Verbinung, ansonsten hält der Server die Verbindung offen.
Cookie: beinhaltet einen Cookie als Wert
Accept: image/*, image/png was ich verarbeiten kann / was
ich bevorzuge.
Server-Seitig:
HTTP/1.0:
Date: Zeitstempel
Content-Type: Was ich sende.
Content-Length: Wie lang ist das, was ich sende.
Content-Encoding: falls die Daten irgendwie Codiert wurden
Location: Wo können die angeforderten Daten gefunden
Werden.
Expires: Wann ist das gesendete nicht mehr aktuell (bei
dynamisch erstellten Seiten).
HTTP/1.1:
Transfer-Encoding: chunked
bevor bekannt ist, wie groß sie ist, und bevor alle
Header-Lines gesendet wurden.
Set-Cookie: Beinhaltet neue Daten für einen Cookie
Möglichkeiten um Session zu erkennen?
- Variablen für die Session über Formulare speichern
- Variablen für die Session in einem Cookie speichern
Möglichkeiten des Caching?
If-Modified-Since:
Wie geht HTTP 1.1 mit Multidomains um?
Host: name
Warum ist HTTP schneller?
Bei HTTP 1.1 prinzipiell persisstente Verbindungen, erst wenn der Client den Header Connection:closed sendet schließt der Server nach der Übertragung die Verbindung.
Transfered-Encoding:chunked
ermöglicht ein früheres sendenvon dynamisch generierten Seiten.
Wie geht das mit den Cookies?
- Der Server schickt eine Set-Cookie: Header Line
- Der Client schickt eine Cookie: Header Line
Bsp.:
Set-Cookie:CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT
Cookie:CUSTOMER=WILE_E_COYOTE
Set-Cookie:SHIPPING=FEDEX; path=/foo
Cookie:CUSTOMER=WILE_E_COYOTE;
Cookie:CUSTOMER=WILE_E_COYOTE; SHIPPING=FEDEX